#: 14869 S3/Shell &/or WorkStn 24-Dec-88 19:26:09 Sb: #DOS 3.3x XCOPY bug Fm: Art Rothstein 70020,516 To: All There is a bug in XCOPY.EXE in version 3.3x of DOS. The problem occurs only in certain cases and only when the target drive is a Novell network disk. (Microsoft must be gloating.) To demonstrate the problem, create directories C:\TEST, C:\TEST\1, Z:\TEST and Z:\TEST\1. In C:\TEST\1, use your favorite text editor to create 9 files, named 1, 2, ..., 9, each containing just the character '1'. Each file is then 4 bytes long, the hex values being 31 0D 0A 1A. Make TEST the current directory on C: and Z:. Make Z: the current drive. Run XCOPY C: /S. Watch your system freeze up, requiring you to bounce the power switch. We have seen the problem in all the DOS 3.3x versions we have inspected, IBM 3.30, Compaq 3.31, AST 3.30, Dell 3.30, Everex 3.30, Wyse 3.30. (The latter four versions are identical, and the Compaq differs only in the version number and, consequently, in the EXE file header checksum.) We ran this test case on an IBM AT model 339 with PC DOS 3.30. Network software versions were: (continued...) *** There is a reply: 14870 Press for next or type CHOICES ! #: 14870 S3/Shell &/or WorkStn 24-Dec-88 19:26:26 Sb: #14869-#DOS 3.3x XCOPY bug Fm: Art Rothstein 70020,516 To: Art Rothstein 70020,516 (...continued) NET3.COM: V2.12 rev. C as reported by NET3 I; V2.12 Rev. D as reported by NVER. IPX.COM: V2.12 Rev. B as reported by IPX I. Server: AN286 V2.12 Rev. A 8/12/88 as reported by NVER; 2.12 Revision 0 as reported by SYSCON. The bug is a simple one, and it's easily patched inline. The program inadvertently changes the DOS disk transfer area (DTA) to an invalid location, does a DOS 4EH call that fails, then changes the DTA to a valid location. In our test case, the invalid DTA is 0:80H, right in the heart of the CPU interrupt vector area. When the target of the XCOPY is a local disk, DOS's 4EH code gets control, and it apparently does not use this invalid DTA. When the target is a network disk, the Netware shell gets control, and it writes to the invalid DTA, eventually causing the freeze. (continued...) *** There is a reply: 14871 Press for next or type CHOICES ! #: 14871 S3/Shell &/or WorkStn 24-Dec-88 19:27:00 Sb: #14870-DOS 3.3x XCOPY bug Fm: Art Rothstein 70020,516 To: Art Rothstein 70020,516 (...continued) The patch is the same for all versions of XCOPY we checked: C:\DOS330>ren xcopy.exe a C:\DOS330>debug a -d 1c50 l 3 280E:1C50 CD 21 8E .!. -a 1c50 280E:1C50 nop 280E:1C51 es: 280E:1C52 -w Writing 2BD0 bytes -q C:\DOS330>ren a xcopy.exe Press for next or type CHOICES ! ADDITION::::: #: 15310 S3/Shell &/or WorkStn 31-Dec-88 01:06:00 Sb: #15288-DOS 3.3 bug redux Fm: Art Rothstein 70020,516 To: Art Rothstein 70020,516 Correction: "Fix one bug and create another." The problem was in my patch. goofed in thinking the DOS 2FH call stuffed DS:DX and was unnecessary. It actually stuffs ES:BX, both of which are used later on in the code. A better patch is C:\WORK1>ren xcopy.exe a C:\WORK1>debug a -u 1c52 l 7 2674:1C52 8E1EAE01 MOV DS,[01AE] 2674:1C56 BA8000 MOV DX,0080 -a 1c52 2674:1C52 es: 2674:1C53 mov ds,[1ae] 2674:1C57 mov dl,80 2674:1C59 -w Writing 2BD0 bytes -q C:\WORK1>ren a xcopy.exe C:\WORK1> Sorry about that.